[00:00.000 --> 00:07.240]  Hey everyone and welcome to the DEF CON Blockchain Village and we are here to present our talk on
[00:07.240 --> 00:14.300]  the title Verifiable Delay Functions for Preventing DDoS or TDoS Attacks on Ethereum 2.0.
[00:14.620 --> 00:21.340]  So this is the agenda for our talk and at the very end of our session if the time allows
[00:21.920 --> 00:26.700]  we'll try to pick up some of your questions and we'll try to answer as many as possible.
[00:27.600 --> 00:34.960]  So wrapping up a quick speaker's introduction. So here am I. My name is Tejasura Sogi. I'm a
[00:34.960 --> 00:41.000]  penetration tester, a blockchain security researcher, founder of RazerSec which is a
[00:41.000 --> 00:47.420]  community that helps people to learn about blockchain security. I'm also a YouTuber as
[00:47.420 --> 00:52.760]  RazerSharp. I post security content on YouTube and the most important thing I'm a cybersecurity
[00:52.760 --> 01:01.040]  enthusiast. I love the world of internet. With that I will ask my partner Mr. Gokul Alex to say
[01:01.200 --> 01:10.420]  a few words about him. Thank you Tejasura. Hi everyone this is Gokul Alex. It's my pleasure
[01:10.420 --> 01:19.360]  and privilege to present in this platform in DEF CON in front of every one of you.
[01:19.360 --> 01:26.440]  I'm the founder of Epic Knowledge Society, one of the fastest growing digital education platform
[01:26.440 --> 01:36.820]  for engineers and entrepreneurs in India. We are a non-profit organization. I am also building a
[01:36.820 --> 01:43.140]  blockchain protocol integrating off-chain and on-chain data called Fusion Ledger. I am
[01:43.140 --> 01:53.920]  representing a collection of cryptocurrencies and platforms in India such as Algorand, Eternity,
[01:53.920 --> 02:00.440]  Elixir, Hashgraph, Horizon and Tezos. I'm also the director of Tezos India Foundation
[02:01.640 --> 02:10.430]  and I've been selected as the MVP for Hedera Hashgraph in 2018. I am a global leader for
[02:11.150 --> 02:16.410]  XS collective created by David Choum known as the godfather of cryptography
[02:17.040 --> 02:24.470]  and blockchain technology. I am a programmer and poet in my personal life. I've been a blockchain
[02:24.470 --> 02:31.570]  security auditor for government, public sector and private sector across various countries. I am
[02:32.410 --> 02:37.440]  actively researching on the convergence of quantum algorithms and post-quantum cryptography.
[02:38.400 --> 02:45.100]  Over to Tejeshwar to get start with the presentation. Awesome! Now let's just start
[02:45.100 --> 02:50.820]  our session and before moving to the attack vectors on proof-of-work, let's get a quick
[02:50.820 --> 02:59.140]  refresher on some of the fundamentals. So let's talk about what is proof-of-work consensus algorithm.
[02:59.140 --> 03:04.860]  Now before that let's talk about what are consensus algorithm. Now consensus algorithms decide like
[03:04.860 --> 03:12.820]  who should create the next block and this decision defines the basic fundamental property
[03:12.820 --> 03:18.360]  of blockchain which is decentralization and decentralized control of power. Now
[03:19.340 --> 03:25.440]  consensus algorithms is all about building fault-tolerant, fault-resilient machines for
[03:25.440 --> 03:32.600]  distributive computing. Now our talk is about the convergence of cryptographic schemes and
[03:32.600 --> 03:39.460]  consensus algorithms. Now consensus algorithms have both deterministic and probabilistic
[03:39.460 --> 03:48.160]  dimensions right. Now consensus algorithms helps us to achieve a consistent state and agreement
[03:48.160 --> 03:54.300]  between participating nodes in a blockchain network. Getting back to our proof-of-work
[03:54.300 --> 04:00.420]  consensus algorithm. Now in proof-of-work consensus algorithm there are miners who
[04:00.420 --> 04:07.100]  compete with each other for the potential valid block creation right.
[04:07.600 --> 04:15.880]  Now there are certain factors involved like that the block header must be less than a set threshold
[04:15.880 --> 04:23.160]  and then there is a mining difficulty. Now mining difficulty defines like the current computational
[04:23.940 --> 04:28.960]  power of the blockchain network and it can also be updated at regular intervals
[04:28.960 --> 04:36.680]  to match the current computational power of the network and it also ensures that the block
[04:36.680 --> 04:43.660]  creation should happen at a certain frequency. Now let's move on to some of the attack vectors
[04:43.660 --> 04:50.160]  or proof-of-work. Now in front of your screen you can see some of the attacks or attack vectors given
[04:51.160 --> 04:58.100]  like the first one which says denial of service or distributed denial of service. Now let's talk
[04:58.100 --> 05:05.020]  over this attack. Now as we have just discussed about the mining difficulty
[05:06.000 --> 05:11.280]  which defines the processing power of the network and can be updated at regular intervals
[05:11.280 --> 05:18.820]  to match the to reflect the changes right in the processing power. Now in most of the
[05:18.820 --> 05:27.360]  blockchain these sudden changes in the processing power are not addressed by the nodes. They can be
[05:27.360 --> 05:37.060]  addressed by the nodes at a scheduled update. Now let's take a scenario. Let's take a scenario of
[05:37.060 --> 05:43.660]  like there are nine machines on a blockchain network and six of them are malicious actors.
[05:43.660 --> 05:49.180]  Six of them are malicious actors. Now they are not doing anything and just chilling in the network.
[05:49.180 --> 05:55.700]  Everything is going as planned. Mining difficulty is working as the way it should. Block creation
[05:55.700 --> 06:02.340]  is happening at a certain frequency and everything is perfect. Now suddenly what the malicious
[06:02.340 --> 06:09.620]  actors decide they decide to turn their machines down. Now what will be the impact of this that
[06:10.260 --> 06:17.060]  now the remaining three machines they have to do the work of nine machines and what will happen or
[06:17.060 --> 06:24.980]  what will be the impact of this that the hash rate will decrease and it will decrease the block
[06:24.980 --> 06:32.940]  creation rate and eventually create a denial of service. So there are other attacks as well
[06:32.940 --> 06:39.060]  like routing attack. So routing attack consists of two parts. First one is the partition attack
[06:39.060 --> 06:46.260]  which divides the blockchain network into two groups and then there is a delay attack which
[06:46.260 --> 06:53.920]  tampers the propagating messages and sends them to the network. Moving on and there are
[06:53.920 --> 07:01.340]  user wallet attacks. Then there are smart contract attacks, transaction verification mechanism
[07:01.340 --> 07:08.720]  attacks and there you can see the well-known 51% of majority attack. Now what is this 51%
[07:08.720 --> 07:16.380]  of majority attack. Now let's take example like there is a group which is in majority
[07:16.760 --> 07:24.600]  a group of malicious actors which is in majority and they can take control over the
[07:24.600 --> 07:32.580]  blockchain network. Now how it can be possible as we know that there is a race between miners
[07:32.580 --> 07:39.980]  for the potential valid block creation. Now if there is a group of malicious actors
[07:40.540 --> 07:50.320]  which is in majority. Now it will have this group will have a higher and better probability
[07:51.010 --> 08:02.820]  to be for the block creation. So this is the 51% attack. Moving on there are some mining pool
[08:02.820 --> 08:11.140]  attacks like selfish mining, forecaster, withhold and like that. So moving on let's talk over DDoS
[08:11.140 --> 08:20.300]  on ethereum. Now there are some attacks that happened on ethereum or there are scenarios as
[08:20.300 --> 08:27.820]  well. So we'll pick up some of them like there was an attack on parity client. So what was the
[08:27.820 --> 08:33.640]  incident like some parity ethereum nodes lost sync with the network because of the following
[08:33.640 --> 08:40.880]  incident. Now what was the incident that if you send to a parity node a block with invalid
[08:40.880 --> 08:47.820]  transaction what will happen. If you send a parity node a block with invalid transaction but with
[08:47.820 --> 08:55.180]  valid header borrowed from another block and what will happen that the node will mark the block
[08:55.180 --> 09:02.160]  header as invalid and ban the block header forever but the header is still valid right.
[09:03.220 --> 09:11.200]  Moving on there was a vulnerability that was found in parity nodes as well. So in may global
[09:11.200 --> 09:17.440]  hacking research collective sr labs claimed that only two thirds of the ethereum client software
[09:17.440 --> 09:23.480]  that ran on ethereum nodes had been patched against a critical security flaw discovered
[09:23.480 --> 09:31.100]  earlier this year. The data reportedly indicated that unpatched parity nodes comprised 15% of all
[09:31.100 --> 09:38.240]  the scanned nodes implying that 15% of all the ethereum nodes were vulnerable to a potential 51%
[09:38.240 --> 09:47.380]  attack. So moving on and there is an interesting underpriced DDoS attacks. Now these are a group
[09:47.380 --> 09:56.880]  of attacks which exploited the vulnerability in the improper cast cost of EVM's opcodes. Now the
[09:56.880 --> 10:04.760]  opcodes were the ext code size and the suicide opcode. The suicide opcode was renamed to self
[10:04.760 --> 10:11.860]  destruct after eip6. We'll talk about that in the next slide. So let's just take the ext code size
[10:12.660 --> 10:21.180]  Now prior to eip150 hard fork, the ext code size opcode only charged 20 gas for reading a
[10:21.180 --> 10:27.920]  contract byte code from disk and then deriving its length. Now as a consequence what happened
[10:27.920 --> 10:34.800]  or what can happen if the attacker sent transactions to invoke a deployed smart contract
[10:34.800 --> 10:41.700]  with many ext code size opcodes, it can cause a two to three times slower block creation rate.
[10:42.780 --> 10:50.860]  Also there was a similar attack that exploited the vulnerability in the proper cast cost of
[10:50.860 --> 11:00.300]  EVM's suicide opcode that was renamed to self destruct as I just said and also the empty code
[11:00.300 --> 11:07.460]  vulnerability in the state drive. So the opcode is meant to remove a deployed smart contract
[11:07.460 --> 11:13.880]  right and then send the remaining ether back to the account designated by the caller.
[11:14.580 --> 11:20.500]  Now if the target doesn't exist a new account is created even though no ether may be transferred
[11:20.500 --> 11:30.860]  but still a new account is created. Now what can happen like the attacker can create empty accounts
[11:30.860 --> 11:39.000]  and that was or that happened like that the attacker created 19 million new empty accounts
[11:39.000 --> 11:46.560]  by the opcode at a very minimal gas consumption and which wasted disk space and increased
[11:46.560 --> 11:56.120]  synchronization and processing time and caused a kind of denial of service right. Moving on to
[11:56.120 --> 12:06.800]  uh attack uh the attackers took advantage of the enterprise tdos attack and that happened
[12:06.800 --> 12:12.740]  between the blocks mentioned in front of your screen. Now what was the impact? It created
[12:12.740 --> 12:21.860]  millions of dead ethereum accounts and also bloated the state database. Now it also created
[12:21.860 --> 12:30.000]  tons of transaction freezes as well. Moving on to the impact of ddos attacks uh the enterprise one
[12:30.760 --> 12:38.180]  and what was the impact that that can be hacks against goethereum client. Hacks can be created
[12:38.180 --> 12:44.260]  against huge amount of cleanup transactions and each cleanup transaction creates large set of
[12:44.260 --> 12:50.960]  freezes. There may be a possibility of hard fork being created and even if the hard fork is created
[12:50.960 --> 12:58.300]  hard forks do not remove the dead accounts right. Moving on to some of the quick fixes to
[12:58.300 --> 13:05.500]  the attacks like scanning an initial set of transaction can be done measuring the traces
[13:05.500 --> 13:10.140]  from each transaction and also checking the frequency of traces in the transactions.
[13:11.880 --> 13:18.520]  Moving on to let's talk about the attack vectors on proof of stake. Now before covering the attack
[13:18.520 --> 13:24.760]  vectors let's do a quick refresher again on the proof of stake consensus algorithm.
[13:25.300 --> 13:31.000]  Now proof of stake is a popular alternative to proof of work. In proof of stake there are
[13:31.000 --> 13:38.560]  validators instead of miners and a validator is selected to forge a block. Also the validator
[13:38.560 --> 13:47.100]  selection depends upon the amount of cryptocurrency a validator has or the amount of stake a validator
[13:47.100 --> 13:55.380]  has and also on the current complexity of the network. And proof of stake has many advantages
[13:55.380 --> 14:02.620]  over proof of work. The first is obviously the security. It provides a better security mechanism
[14:02.620 --> 14:12.980]  against 51% attack. Now as we know like in proof of work owning 51% of the computational power
[14:12.980 --> 14:19.040]  meaning means like gaining control over of the network. But in proof of stake
[14:20.300 --> 14:31.040]  owning 51% of the stakes would be very would be computationally very expensive for an attacker.
[14:31.040 --> 14:38.580]  So that's how it provides a better security. Also it provides better it's energy efficient
[14:38.580 --> 14:48.460]  and provides energy savings. Now also as the ethereum 2.0 is ethereum is transitioning
[14:49.060 --> 14:55.300]  from ethereum 1 to ethereum 2.0 and it is transitioning from proof of work to proof of
[14:55.300 --> 15:02.380]  stake. And there is a casper protocol based on proof of stake. It provides its own security
[15:02.380 --> 15:11.080]  implications like this slashing mechanism which provides slashing of stakes as a penalty
[15:11.080 --> 15:21.780]  to the validator. Now if a validator validates a block it has been awarded but if found that
[15:21.780 --> 15:28.900]  the validator is involved in malicious activity the stakes will be slashed as a penalty and there
[15:28.900 --> 15:37.660]  might be a chance as well that it can lose its privileges to take part in the network consensus.
[15:39.280 --> 15:48.140]  So this was casper protocol. Moving on to let's see some of the attack vectors attacks against
[15:48.140 --> 15:55.800]  proof of stake. You can see a list of attacks in front of the screen. There is a fake stake attack
[15:56.040 --> 16:02.700]  a very interesting attack. Now fake stake attack can be think about as a denial of service. An
[16:02.700 --> 16:12.800]  attacker can devote a node's valuable memory and cpu to a fake chain. Now we know there is a
[16:12.800 --> 16:20.060]  longest chain rule that any chain can suddenly become the accepted version of the ledger.
[16:20.580 --> 16:29.700]  Now validation of a proof in proof of stake is kind of complex. Now it required
[16:29.700 --> 16:39.060]  access to both the block header as well as the contents of block. So like to trigger the stake
[16:39.060 --> 16:46.860]  value for the validator selection right and forcing the node to download data to validate
[16:46.860 --> 16:55.640]  fake blocks. It consumes valuable resources for the node and can eventually result into a denial
[16:55.640 --> 17:03.500]  of service. So fake stake attack can be think about as a denial of service and proof of stake.
[17:03.960 --> 17:08.140]  Moving on to let's see the 3m 2.0 architecture.
[17:08.700 --> 17:17.120]  In front of your screen you can see a beautiful picture defining the road map to serenity.
[17:17.980 --> 17:23.400]  Then there is the current blockchain showing proof of work and proof of stake together.
[17:25.660 --> 17:31.840]  And then you can see a little bit detailed architecture. Like there is a main chain
[17:31.840 --> 17:38.460]  based on proof of work. Then there is a beacon chain based on the casper ffg protocol,
[17:38.460 --> 17:45.200]  proof of stake protocol that we just discussed. And random number generation happens. Now you
[17:45.200 --> 17:51.640]  can see that the beacon chain is cross-linked with the shard chain and underneath there is
[17:51.640 --> 18:00.040]  execution engine as well. Moving on to see some of the 3m 2.0 audit findings. Talking about the
[18:00.040 --> 18:10.560]  Constem audit first. Now Constem did an audit as well and founded some DDoS attack vectors,
[18:10.560 --> 18:17.080]  attack vectors and reported them. Like DDoS attack through creating a mapping between
[18:17.680 --> 18:25.480]  public keys and validator IPs. Also DDoS attack on insecure gRPC connection.
[18:26.440 --> 18:33.280]  So what was the Constem audit? Basically it involved 10 engineers who examined the entire
[18:33.280 --> 18:39.840]  code base over the course of two months. They examined the beacon node logic,
[18:39.840 --> 18:44.300]  validator client, flasher logic and almost everything.
[18:46.570 --> 18:52.750]  So what were the findings? They found a lot of vulnerabilities. Some of them are like
[18:52.750 --> 18:58.650]  granularity of timestamps, pseudo random number generation where two random number
[18:58.650 --> 19:04.990]  generation were needed and then a second pre-made attack on merkle trees as well.
[19:05.630 --> 19:13.250]  Now let's talk about the least authority audit as well. So they did an audit over various subsections
[19:13.250 --> 19:21.210]  like they did a audit over block proposal system. What were the findings? Like a single secret leader
[19:21.210 --> 19:27.170]  election SSLE keeps a selection secret and stops the leak of information to an observer
[19:27.170 --> 19:33.750]  while still allowing the chosen block proposer a fast way to verify to others that it is in fact
[19:33.750 --> 19:41.290]  the proposer. With the information leak passed, the block proposer remains as protected as it is.
[19:41.290 --> 19:46.650]  It would be in proof of work chains but without the computational overhead.
[19:47.950 --> 19:54.090]  We're talking about the findings on a gossip protocol. Now gossip protocols generally suffer
[19:54.090 --> 19:59.390]  from the spam problem. Without a centralized judge, it can be difficult to understand
[19:59.390 --> 20:05.290]  whether a message is legitimate or is spam that is meant to clog a network.
[20:05.630 --> 20:11.610]  This was one of the primary concerns in examining the network layer. In Ethereum 2.0,
[20:11.610 --> 20:17.750]  when a node proposes a new finalized block, the block must be sent to the rest of the network.
[20:18.290 --> 20:25.350]  There is an issue when a dishonest node is capable of sending an unlimited amount of
[20:25.350 --> 20:30.270]  older block messages to the rest of the network with minimal penalty
[20:31.790 --> 20:38.950]  which allows them to overwhelm the network and block legitimate messages.
[20:39.030 --> 20:45.030]  Also, there were findings on slashing messages that we just discussed earlier, the Casper
[20:45.030 --> 20:51.710]  protocol security implication. Now there is a small loophole as well that allowed a node to
[20:51.710 --> 20:58.250]  send an unlimited amount of these types of messages with minimal penalty causing the same message
[20:58.250 --> 21:07.630]  blocking if they send enough of them. Now moving on to talk about DDoS on Ethereum 2.0. Let's take
[21:07.630 --> 21:15.710]  the recently happened Teku attack scenario. Now there were security engineers who
[21:16.750 --> 21:23.230]  did research over public antagonists. They found a Teku attack, created a Teku attack.
[21:23.230 --> 21:29.250]  Now what was the scenario like? Two of the four Teku nodes were targeted by five ordinary machines
[21:29.250 --> 21:36.610]  with a sustained DDoS attack. Now what was the impact? That initial loss of finality was achieved
[21:36.610 --> 21:43.950]  with two or three machines but the others joined with a few epochs to ensure that the network could
[21:43.950 --> 21:52.990]  not recover. Now what was the implementation? You can see a command in front of your screen.
[21:53.470 --> 22:02.210]  So what the command does, it pipes the null byte from Dave's view to the pb command which rate
[22:02.210 --> 22:12.890]  limits to a somewhat arbitrary value high enough to prevent finality. But stay off AWS and IPS
[22:12.890 --> 22:22.270]  radars to ensure the attack continuous. Also the data is then piped back into the netcat command
[22:22.270 --> 22:30.750]  which sends it to the nodes under attack. The while loop is there for when it loses connectivity
[22:31.450 --> 22:34.670]  and command compiles due to container restarts.
[22:36.050 --> 22:41.650]  And moving on to what was the impact of this Teku attack. The effect that the denial of service
[22:41.650 --> 22:48.690]  attack had on the attack net was a prolonged loss finality and required manual intervention
[22:48.690 --> 22:55.330]  to restore the network to a healthy state once the attack stopped. Now the nodes under attack
[22:55.330 --> 23:00.730]  used large amounts of memory while subject to multiple container restarts. Had trouble
[23:00.730 --> 23:07.850]  staying connected to peers and even once nodes local clock was like 20 minutes slow.
[23:08.890 --> 23:14.890]  Moving on to the Teku attack root cause. Now firstly responding to one byte when multiple
[23:14.890 --> 23:20.170]  bytes is a vector. We know for various amplification attacks that we know. But
[23:20.170 --> 23:25.310]  that was not the issue that caused the loss of finality. The second issue is that
[23:25.310 --> 23:31.290]  responses were being written faster than they were read by the attacking peer and the JVM
[23:31.290 --> 23:37.950]  libp2b was not applying any throttling. Eventually the TCP backpressure kicked in,
[23:37.950 --> 23:43.800]  filled up the OS write buffers and the responses wound up being queued in user space memory.
[23:44.130 --> 23:49.210]  This pushed up both the on and off heap memory usage very substantially.
[23:49.930 --> 23:55.230]  Also CPU spikes significantly partly due to the processing power.
[23:55.510 --> 24:01.550]  All those due to processing all those multi-stream messages but mostly because of the resultant
[24:01.550 --> 24:09.890]  memory pressure and GC activity. Now talking about what can be a solution. It's like there
[24:09.890 --> 24:16.490]  can be a straightforward solution like disconnect the peer immediately when an invalid example like
[24:17.050 --> 24:23.110]  multistream message is received. And now also there's a resilience to dot attack as well
[24:23.670 --> 24:29.610]  which increases significantly as increases the number of nodes and diversity of clients,
[24:29.610 --> 24:36.430]  locations and network connections. So this was the takeover attack. We covered
[24:37.130 --> 24:43.270]  consensus algorithms. We talked over proof-of-work, proof-of-stake. We took
[24:43.270 --> 24:50.270]  different attacks, attack vectors as well. We talked over 51% attack, denial of service. We
[24:50.270 --> 24:57.290]  have seen the ATM 2.0 architecture. Also the security implications of cash flow protocol.
[24:57.290 --> 25:05.710]  Now my partner Mr. Gopal Alex will connect with you all the links, the PDF, randomness and DDoS
[25:05.710 --> 25:11.290]  and will connect all of them and present it to you. So over to you sir.
[25:13.090 --> 25:20.550]  Thank you Tejaswar for setting the context, for researching on the randomness in Ethereum 2.0.
[25:21.130 --> 25:28.650]  We will see how randomness is very crucial to the overall engineering and overall design of
[25:28.650 --> 25:35.950]  Ethereum 2.0. If you look at all the current implementations, be it on near protocol,
[25:35.950 --> 25:42.010]  prismatic labs, the beacon chain, there is a crucial play for randomness because all the
[25:42.010 --> 25:47.950]  sharding designs today rely on some source of randomness to assign validators to the shard.
[25:48.670 --> 25:55.910]  Both the randomness and the validator assignment require computation that is not specific to any
[25:55.910 --> 26:03.310]  shard. For this computation, existing designs have a separate blockchain that is tasked with
[26:03.310 --> 26:10.210]  performing operations necessary for maintenance of the entire network. Besides generating these
[26:10.210 --> 26:15.910]  random numbers and assigning validators to the shards, these operations also include receiving
[26:15.910 --> 26:25.310]  updates from shards and taking snapshot of them. This is very important. The shards and taking
[26:25.310 --> 26:30.790]  activity. In older times, we used to take additions, cut additions from the databases.
[26:30.870 --> 26:36.470]  The snapshots are the read-only versions. And also when we process the stakes and slashing
[26:36.470 --> 26:43.050]  in proof-of-stake systems, and when you have to plan the proximity of shard with the leaders
[26:43.050 --> 26:49.790]  and rebalancing the shard, these randomness... so sharding, staking, and randomness have to
[26:49.790 --> 26:56.270]  work together. When you look at all these implementations, whether it's Cosmos Hub in
[26:56.270 --> 27:02.890]  Cosmos, or RelayChain in Polkadot, or BeaconChain in Ethereum and Near, this is the overall
[27:02.890 --> 27:11.110]  architecture. But we have to understand, we cannot afford any simple randomness. We need distributed
[27:11.110 --> 27:17.590]  randomness on blockchain. That is why randomness in blockchain becomes much more complex and more
[27:17.590 --> 27:24.370]  challenging. So many blockchains, if you know, blockchains have different purpose of using
[27:24.370 --> 27:31.290]  randomness. Maybe it's for time stamping, or it could be for games like lottery games, or it could
[27:31.290 --> 27:39.930]  be for proof of replication, like in Filecoin, or in the case of Ethereum, BeaconChain for selecting
[27:39.930 --> 27:46.490]  participants. What happens if a malicious actor can influence such a source of randomness? They
[27:46.490 --> 27:53.210]  can increase the chance of being selected and possibly compromise the security of the protocol.
[27:54.670 --> 27:59.930]  And like we said, distributed randomness is very crucial building block for any kind of
[27:59.930 --> 28:05.630]  applications on blockchain. What are the essential properties of randomness required
[28:05.630 --> 28:12.450]  in a blockchain setup? There are three essential properties laid out. First, it needs to be
[28:12.450 --> 28:19.130]  unbiased. We cannot afford a biased source of entropy. In other words, no participant shall be
[28:19.130 --> 28:24.270]  able to influence in any way the outcome of the random generator. Second, it needs to be
[28:24.270 --> 28:29.730]  unpredictable. In other words, no participant shall be able to predict what number will be generated,
[28:29.730 --> 28:34.970]  or what are the properties of it. Thirdly, the protocol needs to tolerate some percentage of
[28:34.970 --> 28:40.210]  actors that go offline or try to intentionally stall the protocol, like the conventional
[28:40.210 --> 28:45.550]  crash fault tolerance and Byzantine fault tolerance. Now we will look at some of the
[28:45.550 --> 28:51.870]  existing approaches. One of the first approaches is the RANDAO approach, which is the acronym for
[28:51.870 --> 28:56.910]  Random DAO. The general idea is that the participants in the network, first of all,
[28:56.910 --> 29:03.010]  privately choose a pseudo random number. Submit a commitment to the privately chosen number. This
[29:03.010 --> 29:08.910]  commitment could be implemented as a polynomial commitment or a Pedersen commitment. All agree
[29:08.910 --> 29:15.110]  on some sort of commitment using a consensus algorithm. Then all reveal the chosen numbers,
[29:15.110 --> 29:21.390]  reach a consensus on the revealed numbers, and have the XOR of the revealed numbers to be the
[29:21.390 --> 29:26.210]  output of the protocol. This is a pretty straightforward approach, but there are
[29:26.210 --> 29:35.910]  some limitations. It is fairly unpredictable, and it has liveness. We know liveness and safety are
[29:35.910 --> 29:42.770]  two required properties of any consensus mechanism. This provides a great degree of liveness.
[29:42.830 --> 29:50.990]  However, a malicious actor can observe the network once and start to reveal the numbers and choose
[29:50.990 --> 29:58.130]  to reveal or not reveal the number based on the XOR of the number they observed. This allows a
[29:58.130 --> 30:04.250]  single malicious actor to have one bit of influence on the output, and a malicious actor controlling
[30:04.250 --> 30:09.050]  multiple participants have as many bits of influence as the number of participants they
[30:09.050 --> 30:17.490]  are controlling. So there is a proposal, and there is a strong support in this direction,
[30:17.490 --> 30:24.170]  which is to blend RANDAO plus VDF. We will talk about VDF in detail. First, let us understand
[30:24.170 --> 30:30.750]  this approach. To make RANDAO unbiasable, one approach would be to make the output not just
[30:30.750 --> 30:36.170]  an XOR, but something that takes more time to execute than the allocated time to reveal the
[30:36.170 --> 30:41.570]  numbers. If the computation of the final output takes longer than the revealed phase, the malicious
[30:41.570 --> 30:48.850]  actor cannot predict the effect of them revealing or not revealing the number. So we are talking
[30:48.850 --> 30:55.210]  about a computation which is sequential, which cannot be paralyzed by a powerful malicious
[30:55.210 --> 31:01.730]  adversary. Such a function that takes a long time to compute is fast to verify the computation,
[31:01.730 --> 31:07.350]  and has a unique output for each input. It is called as verifiable delay functions,
[31:07.350 --> 31:13.470]  and the design is extremely complex, which we will talk in detail. What is Ethereum's perspective
[31:13.470 --> 31:19.230]  on RANDAO plus VDF? You can find numerous conversations on this in Ethereum research
[31:19.230 --> 31:26.250]  led by Justin Drake and others. Ethereum presents a plan to use RANDAO with VDF as their randomness
[31:26.250 --> 31:32.170]  beacon. Besides that fact, this approach is unpredictable and unbiasable. It has an extra
[31:32.170 --> 31:37.410]  advantage that it has liveness, even if only two participants are online. This is a very
[31:37.410 --> 31:44.770]  interesting property. It requires very, very less live participants compared to any other approach.
[31:44.770 --> 31:51.870]  For the family of VDF linked above a special ASIC, it can be 100 times faster than conventional
[31:51.870 --> 31:58.310]  hardware. That is why there is a strong effort and investment in Ethereum currently to build ASIC
[31:58.850 --> 32:04.950]  hardware for VDFs. So if the reveal phase lasts only 10 seconds, for example,
[32:04.950 --> 32:12.210]  VDF computed on such an ASIC must take longer than 100 seconds to have 10x safety. And
[32:12.210 --> 32:18.790]  does the same VDF computed on the conventional hardware need to take 100x 100 seconds in three
[32:18.790 --> 32:25.990]  hours? Hence, there comes a dependency on hardware. That is the challenge because of this approach or
[32:25.990 --> 32:32.450]  the trade-off in this approach. Now let us look at an early approach which is fairly
[32:33.650 --> 32:40.810]  very popular. This approach is pioneered by DFINITY. In fact, more than one year back or
[32:40.810 --> 32:47.690]  two years back, DFINITY used BLS signature. What is BLS signature? It is known as Bonnet
[32:47.690 --> 32:54.070]  Line Shazam Signature. One of the authors of this cryptographic scheme,
[32:54.070 --> 33:00.550]  Ben Lin, is actually a member of DFINITY. What is this BLS signature? This is a scheme allowing
[33:00.750 --> 33:07.850]  a user to verify that a signer is authentic. This scheme uses a bilinear pairing for verification.
[33:07.850 --> 33:13.410]  We know about bilinear maps in elliptical cryptography, how powerful and formidable
[33:13.410 --> 33:19.730]  they are. So this is a signature scheme built using bilinear pairings. BLS signature is a
[33:19.730 --> 33:26.190]  construction which allows multiple parties to create a single signature on a message which
[33:26.190 --> 33:32.510]  is often used to save the space and bandwidth by not requiring sending around multiple signatures.
[33:32.510 --> 33:39.070]  This is a very interesting property and hence BLS signatures are becoming very popular
[33:39.070 --> 33:47.150]  in more cryptocurrencies and blockchains. A common usage of BLS signatures is in signing
[33:47.150 --> 33:55.590]  BFT protocols, for signing blocks in BFT protocol. When we look at threshold signatures in practice,
[33:56.230 --> 34:01.370]  say there are 100 participants to create blocks and a block is considered final if
[34:02.030 --> 34:08.750]  two by third of them, 67 of them sign on it. They can all submit the parts of the BLS signature
[34:09.630 --> 34:16.790]  and then use some consensus algorithm to agree on 67 of them and aggregate them into a single
[34:16.790 --> 34:24.670]  BLS signature. Any 67 parts can be used to create an accumulated or aggregated signature.
[34:24.710 --> 34:31.050]  However, the resulting signature will not be the same depending on what 67 signatures are
[34:31.050 --> 34:38.910]  aggregated. It turns out that the private keys that participants use are generated in a particular
[34:38.910 --> 34:46.150]  fashion. Then no matter what 67 or less signatures are aggregated, the resulting multi-signature will
[34:46.150 --> 34:52.670]  be the same. This can be used as a source of randomness. The participants first agree on
[34:52.670 --> 34:57.890]  some message that they will sign. It could be an output from a rando or it could be the hash of the
[34:57.890 --> 35:04.890]  block. It really doesn't matter as long as it is different every time and is agreed upon. So here
[35:04.890 --> 35:13.070]  we are blending both randomness and an agreement to create a multi-signature on it. But this has
[35:13.730 --> 35:19.890]  some limitations. The approach as we have seen earlier, even though this is unbiased and
[35:19.890 --> 35:25.130]  unpredictable and is live as long as two by third of the participants are online, though this can
[35:25.130 --> 35:31.610]  be configured to any threshold, while this one by third offline or misbehaving participants can
[35:31.610 --> 35:37.750]  stall the algorithm, it takes at least two by third participants to cooperate to influence the output.
[35:38.530 --> 35:45.310]  This is a big overhead when you consider a live blockchain system. Private keys in the
[35:45.310 --> 35:50.730]  scheme need to be aggregated in a particular fashion. And this process is known as distributed
[35:50.730 --> 35:57.990]  key generation. And this is something which is an ongoing area of research. And there is another
[35:57.990 --> 36:04.770]  interesting approach called ran-share approach. Ran-share approach is an unbiased and unpredictable
[36:04.770 --> 36:11.290]  protocol which can tolerate up to one by third of actors being malicious. It is relatively slow
[36:11.290 --> 36:18.010]  and the paper linked also describes two ways to speed it up called ran-hound and ran-herd.
[36:18.010 --> 36:23.910]  But unlike ran-share, ran-hound and ran-herd are relatively complex. When you look at the
[36:23.910 --> 36:28.770]  details in the paper, you can understand. The general problems of ran-share, besides the large
[36:28.770 --> 36:33.870]  number of message exchange, it requires a lot of back and forth communication between the participants.
[36:33.950 --> 36:43.650]  In fact, O to the O n to n cube messages are required. So this is kind of a gossip.
[36:43.650 --> 36:54.030]  While one by third of the meaningful threshold for liveness is only there, it is low for the
[36:54.030 --> 37:01.050]  ability to influence the output. So the challenge, one is the overhead because of the number of
[37:01.050 --> 37:07.170]  communications required. And second, the number of live participants required.
[37:07.830 --> 37:14.430]  So this is the challenge. The benefit from influencing the output can
[37:14.430 --> 37:20.450]  significantly outweigh the benefit of stalling randomness. Am I audible now?
[37:21.070 --> 37:32.870]  Keshav, can you confirm? Am I audible? Yes sir, you are audible. Okay. So let us continue.
[37:32.870 --> 37:39.670]  The benefit from influencing the output, this is one trade-off when we consider a randomness design.
[37:39.690 --> 37:46.050]  So either the adversary can stall the randomness or influence the output. So this is what we have
[37:46.050 --> 37:51.330]  to see in Rancher approach. If participants control more than one by third of the participants
[37:51.930 --> 37:57.490]  in Rancher and use this to influence the output, it leaves no trace. This is a challenge.
[37:57.490 --> 38:03.310]  Thus, a malicious actor can do it without even ever being revealed. Stalling a consensus
[38:03.950 --> 38:11.610]  is always visible. So if somebody stalls a consensus or creates a fork or disrupts the
[38:11.610 --> 38:17.130]  network, this is visible. But if they influence the output, that leaves no trace. So that is
[38:17.130 --> 38:25.190]  the two aspects of this challenge. And then there are situations in which someone controls one by
[38:25.190 --> 38:31.790]  third of the hash power, having a very powerful machine, a SIG miner or some kind of a very
[38:31.790 --> 38:40.410]  powerful staking pool. So we can't always say that that is an unimaginable or impossible situation.
[38:40.410 --> 38:48.750]  And hence, this Rancher approach creates some kind of a doubt or uncertainty.
[38:49.050 --> 39:00.310]  So we should look at the Near Protocol approach in this scenario. What Near Protocol has done,
[39:00.310 --> 39:06.890]  sharding implementation for Ethereum 2, like a candidate for Ethereum 2, and now they are
[39:06.890 --> 39:13.570]  building the protocols as a separate protocol. So what happens in Near Protocol?
[39:13.570 --> 39:19.510]  They have come up with an approach called erasure code. Let us understand what is this erasure code.
[39:19.750 --> 39:26.770]  Each participant comes up with their part of the network, split it into 67 parts. So this
[39:26.770 --> 39:34.650]  erasure code, it is generated to obtain 100 shares such that any 67 are enough to reconstruct
[39:34.650 --> 39:41.450]  the output. And then they can assign each of the 100 shares to the participants and encode it with
[39:41.450 --> 39:48.710]  the public key of that participant. Then they can share all the encoded shares. Participants use
[39:48.710 --> 39:54.070]  some of the consensus. It could be any Lidl-based protocol like Tendermint to agree on such encoded
[39:54.070 --> 40:02.470]  set extracted from the 67 participants. Once the consensus is reached, each participant takes the
[40:02.470 --> 40:09.590]  encoded sharing, each of the 67 sets published this way, that is encoded with their public key,
[40:09.590 --> 40:16.890]  then decodes all such share and publishes all such decoded shares at once. Once at least 67
[40:16.890 --> 40:23.470]  participants did in the previous step, all agreed upon the sets fully can be decoded and reconstructed,
[40:23.470 --> 40:27.430]  the final number can be obtained as an XOR of the initial part of the participants
[40:27.930 --> 40:32.950]  which came up in the first step. The idea why this protocol is unbiasable and unpredictable
[40:33.390 --> 40:39.510]  is similar to the rand share and threshold signature approach. The final output is decided
[40:39.510 --> 40:45.910]  once the consensus is reached, but is not known to anyone until two by third of the participants
[40:45.910 --> 40:54.670]  decrypt shares encrypted with their own public key. So when we look at all these previous approaches,
[40:54.670 --> 41:01.770]  on one side we can see the verifiable delay functions very solid with the cryptographic
[41:01.770 --> 41:08.570]  technique and threshold signatures also a cryptographic scheme. We can see that randavo,
[41:08.570 --> 41:17.550]  randshare, and the erasure code from near protocols, these are all specific consensus-based
[41:17.550 --> 41:24.190]  approaches. So one side we have threshold signatures, verifiable delay functions, other side
[41:24.190 --> 41:33.090]  we have randshare, randhound, and randherd. Now let us look at verifiable delay functions in detail.
[41:34.010 --> 41:38.550]  What is an anatomy of a VDF? A VDF consists of triple of algorithms.
[41:38.570 --> 41:46.590]  Setup, evaluate, and verify. A setup takes two parameters, lambda and t,
[41:46.590 --> 41:54.910]  the security parameter lambda and the delay parameter t. And it generates a public parameter pp
[41:55.710 --> 42:01.450]  which can fix the domain and range of the VDF. And we can add some additional information necessary
[42:01.450 --> 42:07.490]  to compute or verify it. The second phase is evaluation phase, where you take the public
[42:07.490 --> 42:13.530]  parameter from the previous phase and an input x from the domain and generate an output value y
[42:13.530 --> 42:22.230]  in the range and generate a short proof pi. Finally in the verification phase you use the
[42:22.230 --> 42:28.770]  combination of public parameter x y and pi efficiently to verify that y is the correct
[42:28.770 --> 42:36.810]  output on x. So crucially for every input x there should be unique output of y. When you look at the
[42:36.810 --> 42:44.290]  historic inspirations to VDF, we should first look at the early works of Cynthia Dwork and Moni Navor
[42:44.610 --> 42:51.970]  in early 1990s, who suggested using squaring roots over finite fields, finite field-based
[42:51.970 --> 42:57.710]  puzzles as functions which take a predetermined time to compute and are very straightforward to
[42:57.710 --> 43:05.590]  verify. Incidentally the same Cynthia Dwork and Moni Navor has inspired Satoshi Nakamoto
[43:05.590 --> 43:11.970]  in his pioneering work on peer-to-peer cash in Bitcoin. However their work was considered
[43:11.970 --> 43:19.050]  impractical then because one has to use rather large finite fields to make algorithms useful.
[43:19.090 --> 43:23.350]  And libraries for handling multiple precision arithmetic at the time of the suggestion was
[43:23.350 --> 43:29.210]  order of magnitude slower than the current ones. So we can see that even a lot of promises
[43:29.210 --> 43:35.290]  on elliptical curve cryptography which uses finite fields came only in the early 2000s.
[43:35.590 --> 43:41.110]  What are the essential properties of VDF? Now we have seen how do we construct a VDF.
[43:41.110 --> 43:46.950]  What are the essential properties? Firstly it has to be sequential. Honest parties can compute
[43:46.950 --> 43:55.910]  y and pi given we have public parameter nx in t sequential steps while no parallel machine
[43:55.910 --> 44:00.130]  adversary with a polynomial number of processors can distinguish the output
[44:01.030 --> 44:07.690]  y from random input significantly in fewer steps. So this is very important.
[44:07.690 --> 44:15.310]  The output should be indistinguishable with any other randomness even if the adversary has
[44:15.990 --> 44:21.730]  a polynomial number of processors so that they can compute they can execute all of them
[44:22.190 --> 44:27.090]  in a very efficient polynomial time. They should not be able to distinguish this
[44:27.090 --> 44:33.210]  output from VDF from other randomness and it should be efficiently verifiable.
[44:33.970 --> 44:38.810]  The verify operation should be as fast as possible for honest parties to compute.
[44:39.010 --> 44:46.350]  So the verification time should be as small as polynomial logarithm of the time taken to
[44:46.350 --> 44:53.730]  generate it or construct it and it should be unique as we said before for every input x
[44:53.730 --> 45:01.030]  it should be difficult to find an y for which the same combination of public parameters
[45:01.030 --> 45:09.330]  x y and pi gives the same output. Now there are some more additional properties of VDF very
[45:09.330 --> 45:15.190]  important for actual implementation. One of the first one is it should be decodable. A VDF is
[45:15.190 --> 45:21.470]  decodable if there exists a decoding algorithm such that the combination of evaluate and decode
[45:21.470 --> 45:27.890]  form a lossless encoding scheme. This is very much required for a practical use of VDF and
[45:27.890 --> 45:36.890]  it should be implemented. Hi sir, sorry for interrupting. Yes. So we can take like 10
[45:36.890 --> 45:44.490]  more minutes because it's already like just 30. So yep. Yeah, I'll move fast. So the second
[45:44.490 --> 45:51.130]  property is the incremental property which will help us to compute the output with zero knowledge
[45:51.130 --> 45:58.010]  proofs or any recursive proofs and the size should be smaller. And the main innovations if
[45:58.010 --> 46:04.690]  you look at the main VDF constructions are the first construction is in the original paper by
[46:04.690 --> 46:13.850]  Dan Bone, Ben Fish and others in 2018 which uses injective rational maps. But however this is a
[46:13.850 --> 46:20.710]  very complex implementation and hence even the author said this is a weak VDF. Later two other
[46:20.710 --> 46:27.750]  approaches were proposed by Paisarch and other by Veselovsky independently arriving at extremely
[46:27.750 --> 46:34.390]  similar constructions but more practical by using repeated squaring in groups of unknown order.
[46:34.390 --> 46:39.070]  These constructions are based on modular exponentiation arithmetic where Paisarch
[46:39.470 --> 46:46.210]  and Veselovsky suggested to iteratively compute squarings in RSA groups with a large
[46:47.090 --> 46:55.050]  prime modulus. Innovations in VDF. One very crucial difference in VDF with others is VDF
[46:55.050 --> 47:02.990]  has a setup phase. Within the setup phase we set the public parameters for configuring the VDF.
[47:02.990 --> 47:09.110]  So any node who need to solve the VDF will use the public parameters. And some VDF also allow
[47:09.110 --> 47:14.330]  generating a proof so that you can use this in conjunction with the computational proofs of
[47:14.330 --> 47:21.770]  integrity and we can use it in a multi-party computation setup. Now let us see how we can
[47:21.770 --> 47:28.730]  use VDF for DDoS prevention. One of the first approach for using VDF for DDoS prevention was
[47:28.730 --> 47:37.470]  from IOTA. IOTA is a IOT ledger which uses tangled consensus which is not strictly a blockchain but
[47:37.470 --> 47:42.370]  they have come up with a lot of innovations in cryptography in the past like they have adopted
[47:42.370 --> 47:48.770]  windermere's one-time signature. So what IOTA has implemented is a DDoS prevention mechanism.
[47:48.770 --> 47:57.070]  IOTA is actually an IOT ledger with heterogeneous IOT devices. So they propose to use VDF for
[47:57.070 --> 48:02.310]  VDF as a DDoS prevention mechanism where nodes are required to compute exactly
[48:03.010 --> 48:10.290]  the prime modular squarings for an input message. Calibrating the VDF evaluation on different
[48:10.290 --> 48:15.690]  hardware and optimizing the time need to verify the correctness of the puzzle through multi-
[48:15.690 --> 48:20.570]  exponentiation techniques. That is what they have done. So what they have done is they have used
[48:20.570 --> 48:28.650]  different kind of hardware like laptops, FPGAs and different IOT hardwares like Raspberry Pis
[48:29.170 --> 48:36.470]  and different other devices and then they optimize the time. They continuously calibrated what would
[48:36.470 --> 48:47.150]  be the time for constructing the VDF, evaluating the VDF and verifying the VDF. So they compared it
[48:47.150 --> 48:54.590]  with for their purpose. Actually IOTA doesn't have a system like a proof of stake. Hence their concern
[48:54.590 --> 49:02.490]  was how to use it instead of proof of work and that's how they use VDF. So how did they use it?
[49:02.490 --> 49:09.910]  In the evaluation phase, every node decides to generate a transaction and all those nodes need
[49:09.910 --> 49:17.610]  to solve a VDF such that the input is the hash of the transaction issued by the same node and the
[49:17.610 --> 49:23.710]  proof that they generate. The node also generated proof to facilitate the verification task which
[49:23.710 --> 49:29.490]  gossip along with the transaction. So they share the proof along with the transaction. Verification
[49:29.490 --> 49:36.830]  happens when a new transaction is received. A particular node verifies whether the VDF is
[49:36.830 --> 49:43.490]  solved correctly by the node which sent the transaction. If yes, it forward the transaction.
[49:43.490 --> 49:50.130]  In IOTA, it has some kind of tipping mechanism or forward mechanism where every node
[49:50.130 --> 49:56.050]  which receives an input has to send it to two other nodes. That is how the tangle works.
[49:56.050 --> 50:01.550]  Let us look at how VDF integration is implemented in IOTA. There are evaluators
[50:02.130 --> 50:09.130]  and evaluators evaluate and generate the proof from the input to the VDF. They use both hash and
[50:09.130 --> 50:15.270]  the VDF and then when they generate transaction, transaction nodes will have VDF in it and then
[50:15.270 --> 50:22.030]  the verifier will verify whether the VDF is accurate which they can do it fast. If it is true,
[50:22.030 --> 50:26.890]  they broadcast to neighbor. If it is false, they discard it. We can configure the difficulty
[50:27.450 --> 50:34.290]  and the modulus in this VDF implementation IOTA. This is an important property which is mentioned.
[50:34.290 --> 50:39.290]  VDF difficulty can be configured that determines the number of sequential operations to solve
[50:39.290 --> 50:47.650]  and update the VDF. The second one, the prime modulus, the RSA modulus which we use for the RSA
[50:47.650 --> 50:53.370]  based groups of unknown order. And the third thing, they also use a cryptographic hash function.
[50:54.190 --> 51:01.690]  Now let us quickly talk about our approach. Our approach is based on a closer view at what is
[51:01.690 --> 51:08.350]  required for Ethereum 2.0 and what are the current capabilities we have in 2.0 like sharding, stake
[51:08.350 --> 51:16.670]  and random oracles and also the presence of different proof, zero-knowledge proof implementations.
[51:16.670 --> 51:23.250]  But one key difference what we would like to propose is, we are proposing VDF based on
[51:23.250 --> 51:31.090]  super-singular isogenic cryptography, not based on the RSA based unknown groups of unknown order
[51:31.090 --> 51:38.890]  approach or adiabatic adaptive root assumption approach of PISTRAC and Wyslawowski. We also
[51:38.890 --> 51:45.750]  wanted to bring in an approach known as single secret leader selection. And we want to use this
[51:45.750 --> 51:53.530]  VDF for selecting a secret leader, a single secret leader from data shards each time.
[51:53.530 --> 51:59.470]  And we also want to use them in conjunction with random oracles. And we want to authenticate the
[51:59.470 --> 52:05.230]  nodes participating in stake mechanism using VDF based delay authentication,
[52:05.230 --> 52:11.310]  which is also proposed recently. And then we want to use randomness,
[52:11.310 --> 52:16.650]  ran-share and ran-hound powered beacon chain. So this is how we visualize our approach.
[52:16.650 --> 52:25.550]  We use isogeny based VDF generator and these VDF generators will be used to create random oracles.
[52:25.790 --> 52:32.550]  These random oracles will source to the shard chains with ran-hound and ran-share. And that's
[52:32.550 --> 52:38.410]  how we decide which shard to move in the proximity. And then the shards will be part of the beacon
[52:38.410 --> 52:44.570]  chain where we will have a secret single leader selection and delay authentication. And then
[52:45.330 --> 52:50.030]  finally, which will be added to the main chain based on...
[52:50.030 --> 52:55.950]  Hi sir, sorry again for interrupting. Ajit sir is saying we can like conclude our talk.
[52:55.950 --> 53:00.230]  So we can just quickly wrap up and just talk about the isogeny, right?
[53:00.230 --> 53:06.090]  Yeah, I'll just quickly show what we have. We have already done a prototype on this random oracle
[53:06.090 --> 53:14.450]  using the VDF from the software. You can see the code in our repository. And we also giving
[53:14.450 --> 53:19.410]  the highlight of the single secret leader selection mechanism. You can find the research
[53:19.410 --> 53:25.890]  paper which is substantiating this again from Dan Boneh and the node topology. And please let me
[53:25.890 --> 53:32.830]  hand over to Tejas to talk about the beautiful aspects of isogeny based VDF quickly.
[53:33.630 --> 53:40.370]  So, hey everyone. I will just quickly wrap up our presentation and we are just in more finale.
[53:40.450 --> 53:47.830]  And I will just quickly talk about the isogeny based VDF. Now, what is an isogeny? It is based
[53:47.830 --> 53:55.570]  on the idea of elliptic curve cryptography and Diffie-Hellman key exchange. So in isogeny,
[53:55.570 --> 54:00.650]  there are a group of elliptic curves. So you can think about that there are two elliptic curves,
[54:00.650 --> 54:08.270]  E1 and E2. We can do a mapping or a function of like, let's say, point P from elliptic curve E1
[54:08.270 --> 54:16.750]  to point Q at elliptic curve E2. And this mapping is called as the isogeny. Now, our secret here is
[54:16.750 --> 54:23.810]  then the isogeny here and the public key you can think about as the elliptic curve. And we can do a
[54:23.810 --> 54:30.090]  secret share exchange by mixing our secret key with other side's elliptic curve. Next slide.
[54:31.010 --> 54:42.550]  Next. Next, moving on. So, yep, let's see a quick construction. So we'll set up, we'll take
[54:42.550 --> 54:47.990]  prime number n, we'll take a supersingular curve E, and performing a random non-backtracking
[54:47.990 --> 54:55.090]  walk of length t, have as outcome the isogeny phi, and its dual as phi dash. I call it as phi dash.
[54:55.090 --> 54:59.410]  Now, choosing a point P, we'll compute the isogeny of the point P,
[54:59.410 --> 55:06.010]  and there will be output as isogeny dual, the elliptic curves E and E dash, the point P,
[55:06.010 --> 55:15.190]  and the isogeny of point P. Next. This is how isogeny look like, mapping between two elliptic
[55:15.190 --> 55:25.750]  curves. Next. And the final slide, how the evaluation and verification works in an isogeny
[55:25.750 --> 55:33.730]  based medium. So for the evaluation, if we are receiving a random point Q, we have to compute
[55:33.730 --> 55:44.090]  the isogeny dual of that point Q. And for the verification part, we will refer to our previous
[55:44.090 --> 55:50.070]  knowledge of the slides, which were field pairings. So how the verification can be done,
[55:50.070 --> 55:56.650]  just simply a field pairing of the point P with the isogeny dual of the point Q,
[55:56.650 --> 56:03.090]  and that should be equal to the field pairing of isogeny of the point P and the point Q.
[56:03.090 --> 56:08.790]  So having said that, we are done with our presentation, and I will hand over to Gokul
[56:08.790 --> 56:16.950]  sir to say the final words. It's a great honor for us to present our compilation of thoughts on
[56:17.510 --> 56:25.590]  applying powerful properties of randomness, unbiased randomness and entropy, for the
[56:25.590 --> 56:32.790]  overall transformation of the consensus and cryptography and to make Ethereum 2.0 much
[56:32.790 --> 56:40.330]  more stronger and make sure that every chance of DDoS attack can be prevented from the sharding,
[56:40.330 --> 56:46.690]  shard to the main chain itself. Overall, so this is a randomness engineering that we propose.
[56:46.690 --> 56:51.950]  We have done our first level of prototype. We would like to move to the next level by
[56:51.950 --> 56:59.910]  integrating isogeny VDF from the SIDS library and the SS-isogeny library. And then we would
[56:59.910 --> 57:06.770]  also want to blend single secret leader selection, and we would like to do it on the RANDAO.
[57:06.930 --> 57:12.030]  We have already participated in the Starkware VDF hackathon. We have used the
[57:12.030 --> 57:19.610]  VDF from Starkware and built random oracles and applied on RANDAO. Now we are excited to go
[57:19.610 --> 57:25.370]  forward. Thank you so much again for Blockchain Village, DEF CON for giving us this opportunity.
[57:25.370 --> 57:30.910]  It's an honor. It's a lifetime opportunity for us. Thank you so much once again. Looking forward
[57:30.910 --> 57:32.550]  to your questions and comments.
